首先声明一下啊，其实最后并没有点亮5775c，但是coreboot确实跑起来并且成功引导sata上的ubuntu，进入桌面了。

去年许多迷你桌面系统都挺火的，包括联想M73，戴尔3020，和这篇东东要讲到的惠普800 G1 DM，他们都是4代平台。去年也有一艘神奇的大船靠岸，5775C 船票只要400，据说魔改BIOS后可以在4代平台点亮。于是呢我就上车了，并且买了800 G1，开始翻车之旅。

由于手头没有4代亮机U，同时还花费33元买了一个G3220，商家发来了G3240。谁知道这垃圾U，居然在矿潮中涨价了，一度涨到80+....

为什么选择800 G1 DM，而不选择有魔改BIOS放出来的那些主板呢？

首先，800 G1 有两个DP接口，这可太文明了，毕竟不能浪费Iris Pro 6200这颗旧时代最强核显。其次这个小主机有一个m.2接口，Q87 可以搭配特定CPU支持AMT。最后如果翻车了，再买个4代U，装个黑苹果也不是不能用(滑稽... ，失败了就当学习coreboot吧。

其实购入前已经看过coreboot和Intel FSP相关的开源代码了，4代平台已经有自动化移植工具，一些4代桌面主板也被coreboot官方支持。另外Broadwell-U系列SoC也被coreboot支持。似乎事情也没有那么难。

比如这里有一篇4代标压移动平台适配coreboot的详细步骤：Porting coreboot to a Haswell / Lynx Point laptop: GIGABYTE P34G v2 。他给出了两个自动化工具的patch，不过后来这些改动已经被合入了，并且后来mytbk大佬也做了更多改进。

参考这个移植步骤，和coreboot已有的4代平台支持，理想状况下点亮800 G1 DM应该是不难的。这个板子用的EC/SuperIO是NPCD379，相近型号的NPCD378在compaq_8200_elite_sff和z220_sff_workstation已经有不错的支持了。

于是第一次车就这么翻了。在调整好编译错误，加入原机BIOS分离出来的ME，VBT和IFD之后。

这个日志是从Flash里面读取回来的，需要开启SPI Flash console output。这样一次调试其实是比较麻烦的，需要编译，然后擦写一次flash，再读取一次取回日志。

到此显然是内存初始化有问题了。问题出在哪呢，然而没有办法确认。因为mrc是二进制提供的，通过一个接口调用，完全黑盒。此时mrc的确返回了内存训练成功的结果，但是接下来的简单内存测试却跑飞了，它承诺的成功并没有真的成功。

没有进展的情况下，我就来玩点新东西吧。首先是一个灵车诊断卡。

通常电脑不开机，可以通过诊断卡代码判定卡在了哪一个步骤，coreboot也不例外，提供了LPC输出Post Code的支持，所以简单的问题可以通过这个代码判定。至于LPC定义哪里找呢？800 G1 DM这个主板没有图纸，可是背面有一个TPM芯片。TPM也是通过LPC连接到南桥的，刚好这枚TPM芯片有手册，可以测量引脚和下图空焊位的通断来确定线序。

诊断卡提供的Post Code毕竟信息量太小了，有没有更好的获取启动日志的方式呢，比如提供一个串口？当然，使用串口输出日志理论上是可以的，但是串口似乎接在了SuperIO上，这个主板没有图纸，找不到相应的引脚。

然而在Intel平台上，还有一种让我略感神奇的调试端口，EHCI Debug Port，也就是使用USB端口。大致只要一个支持OTG的USB设备，启用OTG模式，并且设置好USB Gadget Support，EHCI Debug Device Gadget，EHCI Debug Device mode (serial)这些编译选项，编译出内核模块g_dbgp并且加载之后，将会有一个串口设备出现。

此时只要通过终端打开串口，然后连接OTG口至目标设备的EHCI Debug Port，这样目标设备通过EHCI Debug Port输出的信息就能被看到。此处参考coreboot的EHCI debug即可，它提供了工具和详细的操作步骤。由于Linux内核也支持通过EHCI 调试端口输出启动日志，因此可以先用原机BIOS与Linux内核确定端口有效性。具体到800 G1 DM这个机器上，这个测试步骤还需要打开BIOS中的EHCI Debug功能。

对于EHCI debug dongle，我使用了闲置的Dir-505。SoC用的是ar9331的马甲，支持OTG，也带有usb端口。但是经过好些尝试之后，并且咨询路由开发者大佬之后，确定ar9331的usb控制器角色是通过引脚电平控制的，开启OTG必须改动相应的电阻，否则无法正确加载驱动。

干掉一个无法启动的板子之后，找到了对应的电阻位置，有需要的话再标注一下吧。刷上开启好功能的Openwrt，一个EHCI debug dongle就做好了。打开coreboot的EHCI debug功能之后，就能看到输出啦。

到这里coreboot的尝试就搁置了，但是期间一直在关注coreboot的发展，因为有一个开发者正在做Haswell和Broadwell代码的合并！不过直到今天，2021年底，这个合并也没有彻底完成，但是好像这位大佬一直都在努力中。后来又看到了一个提交，是检查寄存器值来判定内存控制器是否接受内存初始化，也就是MRC返回的成功，确实不一定真的成功。

回过头来想，这里的内存初始化失败，其实相当不应该。即使我使用的是chromebook Haswell ULT平台提取出来的MRC，在官方支持的桌面平台上也是能用的，为什么到我这里就初始化内存失败呢。

第二次试验是因为从群友处白嫖(约等于)到了一枚i5 4590。在之前我有一种猜测，可能是G3240这颗CPU不被MRC所支持，换个酷睿就好了。于是我又重新拉取了coreboot的最新开发分支，然后解决冲突后，又编译了一个版本。插电，自动开机，不亮，关机读一下日志。震惊，居然还是内存初始化失败.......

这不科学啊。思考一通之后，我觉得MRC肯定是没问题的，应该是内存相关的配置出了问题。看来看去，只有一个spd map的配置可能有问题了，先前mytbk大佬也提到需要确认spd map的正确性。

i2c 地址0x50是正确的，这个能确定无误，因为开启更高的日志等级后能够看到spd是被正确读取到了。

但是i2c地址对应哪个memory channel的哪个rank，这个我之前没有找到确定的方法，只是按顺序填了下来。

那就一个个枚举吧，最后枚举到上面这个通道和地址配置时，上电后屏幕居然出乎意料又虽迟但到的有反应了，随后题图的SeaBIOS出现了。最终他点亮了！

可能是因为sata口接的硬盘使用gpt+efi，SeaBIOS并不能正常引导。后面替换payload为tianacore之后，虽然efi阶段的显卡因为没有配置好，没有输出，但当linux内核启动之后，显示器就正常亮了起来，最后成功进入ubuntu！

虽然最初的目标还没有实现，但是假以时日，等到了broadwell和haswell代码合并的那天，可能5775c真的能在800 g1 dm上点亮了。(其实我尝试过把broadwell的mrc和refcode及相关胶水代码覆盖到haswell上，但失败了，这里面有一些配置的问题，mrc接口也有abi的问题，总之没有成功）

最后感谢mytbk和老狼和其他大佬提供的支持。

最后的最后，希望有更多人来一起玩coreboot。如果你还不认识coreboot，不妨看看上面两位大佬的文章和博客。希望这个开源但又没有完全开源的自由固件，能够让更多好玩的事情发生。